Nice, the overall approach here makes sense. Leaving some minor comments.

Reviewed 1 of 4 files at r3, all commit messages.
Reviewable status: complete! 0 of 0 LGTMs obtained (waiting on @wenyihu6)

pkg/kv/kvserver/rangefeed/event_size.go line 91 at r4 (raw file):

func checkpointRangeFeedEvent(span roachpb.RSpan, ts resolvedTimestamp) kvpb.RangeFeedEvent {
	var event kvpb.RangeFeedEvent

Will these cause memory allocations? We should avoid those on the hot path (we do a bunch of them already, but should try not to add any more). You can find out by writing a small benchmark using dev bench --bench-mem, or using scripts/goescape to see if any of these escape to the heap.

pkg/kv/kvserver/rangefeed/event_size.go line 110 at r4 (raw file):

func (ct ctEvent) futureMemUsage(span roachpb.RSpan, rts resolvedTimestamp) int64 {
	if rts.ForwardClosedTS(context.Background(), ct.Timestamp) {

We shouldn't call ForwardClosedTS here, nor rts.Init() for initRTS. These will actually advance the rangefeed's resolved timestamp, which will cause incorrect behavior when a later call e.g. during consumeEvent sees ForwardClosedTS return false because the resolved timestamp was already advanced when computing the event size.

pkg/kv/kvserver/rangefeed/event_size.go line 196 at r4 (raw file):

	switch re.GetValue().(type) {
	case *kvpb.RangeFeedValue:
		memUsage += rangefeedValueOverhead + int64(re.Size())

Size() won't really give an accurate representation of the memory size, as it computes the Protobuf-encoded wire size (which uses stuff like varints to compress integers, and omits fields with zero values).

I wonder if it would be sufficient here to simply compute the event memory usage, and assume that the Protobuf events have a size that's roughly equal to it. In other words, just use memUsage() and drop futureMemUsage(). How large is the diff usually?

pkg/kv/kvserver/rangefeed/scheduled_processor.go line 703 at r4 (raw file):

		if p.rts.ConsumeLogicalOp(ctx, op) {
			// May publish checkpoint we are over accounting here -> we should have a separate token for publishcheckpoint maybe
			p.publishCheckpoint(ctx, alloc)

I think this is fine, but we could also consider just passing a nil alloc here and ignoring these events. They're most likely few enough that they won't matter, and they should be small compared to the events that trigger them (that we've already allocated budget for).